Collaboration intergouvernementale en matière de confiance et d'attestations numériques

Politiques techniques du réseau CANdy

Les politiques techniques du réseau CANdy seront alignées sur les meilleures pratiques de Hyperledger Indy, sauf mention explicite du contraire, et seront également enrichies par les travaux du groupe sur les politiques techniques.

Pour plus d’informations, veuillez consulter le site web ici :

https://wiki.hyperledger.org/display/indy

Résumé technique du réseau CANdy

Le réseau CANdy est conçu pour se conformer aux normes et protocoles suivants :

Item	Détails
Protocole technique	• Hyperledger Indy v1.13.2 [-rc3] (ou supérieur) - W3C DID Core v1.0
Méthode DID	did:indy:candy : v1.13.x
Norme pour le programme de service	Toute personne utilisant le résolveur universel did:indy:candy peut traduire un DIDDoc did:indy:candy.
Norme pour l’attestation vérifiable	AnonCreds 1 (version actuelle) (JSON) AnonCreds 2 (futur) (JSON) W3C Verifiable Credentials JSON-LD (futur)
Standard de révocation pris en charge	Spécification de révocation INDY selon la documentation
Profils d’interopérabilité	• Résolveur universel DIF did:indy:candy • did:indy
Éléments essentiels de l’identité numérique	• BLS-Signature • X25519 • ED25519

Exigences générales relatives aux nœuds

Le Conseil de gouvernance de la Collaboration intergouvernementale en matière de confiance et d'attestations numériques (CICAN) reconnaît que, actuellement, les performances des nœuds Indy commencent à se dégrader lorsque le nombre de nœuds dépasse 25.

• Le réseau CANdy nécessite un minimum de quatre nœuds pour être opérationnel.
• Le nombre maximum de nœuds est de 25 (comme indiqué ci-dessus).
• L’ajout de nœuds DOIT être contrôlé au niveau du réseau afin de satisfaire aux exigences minimales/maximales en nombre de nœuds.
• Assurer la mise à jour et la facilité d’accès des informations de contact dans la Liste de contacts du réseau CANdy.

Les politiques techniques des opérateurs de nœuds du réseau CANdy seront alignées sur les meilleures pratiques de Hyperledger Indy et du réseau Sovrin, sauf mention explicite du contraire, et seront également enrichies par les travaux du groupe sur les politiques techniques.

Un nœud d’Intendant :

1. DOIT être disponible pour fonctionner en tant que nœud validateur ou nœud observateur (état futur) sur l’un des registres distribués formels qui composent le réseau CANdy.
2. DOIT exécuter une version du code source ouvert CANdy telle qu’approuvée et désignée par le Comité directeur.
3. DOIT faciliter une mise à niveau vers une nouvelle version du code source de CANdy qui a été :
   1. Recommandée par l’équipe des opérations du réseau CANdy; et
   2. Approuvée par le Conseil de gouvernance CICAN. Les décisions du Conseil de gouvernance sont prises après avoir obtenu un consensus de tous les membres.
4. DOIT enregistrer toutes les données de configuration du nœud requises par le registre distribué en temps opportun, en maintenant les informations à jour dans les trois jours ouvrables suivant les changements.
5. DOIT avoir au moins deux (2) personnes qualifiées en informatique affectées à l’administration du nœud, ainsi qu’au moins une autre personne disposant d’un accès adéquat et d’une formation pour administrer le nœud en cas d’urgence (par exemple, si le réseau CANdy est incapable d’atteindre un consensus ou est attaqué).
6. DOIT fournir les coordonnées de tous les administrateurs au Comité directeur CICAN : Liste de contacts, dont l’exactitude est vérifiée au moins trimestriellement (par exemple, en envoyant un e-mail et/ou un SMS et en confirmant la réception).
7. DOIT maintenir une sauvegarde système, un instantané ou une image de manière que la récupération du système après une défaillance puisse être effectuée en une heure ou moins.

Politiques techniques pour la gestion des nœuds du réseau CANdy

Les exigences suivantes s’appliquent aux nœuds Intendant sur le réseau de production CANdy. Les nœuds sur tout autre réseau de test CANdy DEVRAIENT être similaires à ceux-ci, mais les exigences peuvent être réduites de DOIT à DEVRAIT.

1. Pour intégrer un nœud supplémentaire au réseau CANdy, le membre DOIT le présenter au Conseil de gouvernance CICAN. L’ajout de nœuds au réseau DOIT être approuvé par le Conseil.
2. Pour retirer un nœud du réseau CANdy, le membre DOIT le présenter au Conseil de gouvernance CICAN. La suppression de nœuds du réseau DOIT être approuvée par le Conseil.
3. Lors du retrait d’un nœud du réseau CANdy, le Comité directeur CICAN DOIT confirmer que l’Intendant ou le(s) nœud(s) ne sont pas les seuls détenteurs des dossiers Genesis du réseau CANdy.
4. DOIT fonctionner sur du matériel robuste de type serveur.
5. Si un nœud est exécuté sur une machine virtuelle, l’Intendant :
   1. DOIT exécuter un hyperviseur grand public qui reçoit des correctifs en temps opportun de son fournisseur ou de la communauté.
   2. DEVRAIT appliquer régulièrement les correctifs de l’hyperviseur.
6. Le nœud DOIT fonctionner dans un système d’exploitation dédié au programme de validation (c’est-à-dire une machine physique ou virtuelle à usage unique qui DOIT exécuter le code source libre CANdy); PEUT être exploité avec d’autres logiciels approuvés par le Comité directeur CICAN ou un groupe technique délégué; et NE DOIT PAS exécuter aucun autre logiciel. Les logiciels nécessaires au support du nœud, tels que les logiciels de surveillance, de sauvegarde et de gestion de la configuration, sont approuvés en tant que catégorie générale. Toutefois, les Intendants DEVRAIENT consulter le Comité directeur CICAN ou un groupe technique délégué au sujet de tout logiciel qui communique entre le nœud de l’Intendant et l’extérieur.
7. DOIT exécuter un serveur avec des versions de systèmes d’exploitation compatibles avec les exigences du nœud Hyperledger Indy, conformément aux notes de mise à jour émises.
8. DOIT avoir une puissance de calcul minimale (à partir de la mi-2022, deux (2) cœurs ou plus sont considérés comme adéquats).
9. DOIT avoir une mémoire vive suffisante (à partir de la mi-2022, 8 GB de mémoire vive sont considérés comme adéquats).
10. DOIT disposer d’au moins 250 GB, avec la possibilité de passer à 1 To, d’espace disque fiable (par exemple, RAID), avec une partition de démarrage de taille adéquate.
11. DOIT disposer d’une connexion Internet à haut débit avec des canaux redondants et hautement disponibles (à partir de la mi-2022, 1 Gbps est considéré comme suffisant).
12. DOIT disposer d’au moins deux cartes réseau dédiées au trafic de consensus du nœud de validation CANdy, et d’une carte réseau différente pour traiter les demandes externes. Chaque NIC doit avoir une adresse IP stable, statique, à routage mondial.
13. DOIT disposer d’une horloge système démontrablement synchronisée avec des serveurs NTP bien connus.
14. DEVRAIT avoir une alimentation électrique compatible avec les systèmes à haute disponibilité.

Politiques de sécurité pour la gestion des nœuds du réseau CANdy

Un Intendant:

1. DOIT conserver les clés Intendant sur un système séparé de celui qui exécute leur nœud. Ce système, appelé « système CLI (Command Line Interface) », utilise les clés Intendant pour autoriser le nœud à participer à l’ensemble des outils système, et constitue donc la base de la confiance pour le nœud et l’identité de l’Intendant sur le réseau. Le système CLI n’est pas nécessairement doté de matériel haut de gamme, mais en termes de meilleures pratiques en matière de sécurité informatique, il doit respecter ou dépasser les normes du nœud (voir les éléments suivants). Ce système peut être conteneurisé et doit être disponible pour l’Intendant selon les besoins.
2. DOIT fournir un certificat attestant que son nœud opère dans un centre de données verrouillé avec des niveaux de sécurité appropriés, ainsi que les spécifications ciblées (par exemple, conformité à la norme SSAE 16 de type II; d’autres normes peuvent également être acceptables).
3. DOIT garantir que son nœud est isolé des systèmes appartenant à l’Intendant (car le nœud de validation est publiquement visible, ce qui en fait un candidat inapproprié pour accéder aux réseaux internes nécessitant des privilèges).
4. DOIT garantir que son nœud et ses systèmes sous-jacents utilisent une authentification de pointe pour l’accès à distance, comprenant au minimum un SSH avec clé, accompagnée d’un mot de passe, une restriction d’accès par adresse IP source via le pare-feu, et l’authentification à deux facteurs chaque fois que cela est possible.
5. NE DOIT PAS autoriser l’accès (à distance ou local) au nœud ou aux systèmes CLI par des personnes autres que les administrateurs assignés.
6. DEVRAIT appliquer les derniers correctifs de sécurité dans un délai d’une semaine ou moins (le délai recommandé est de 24 heures ou moins).
7. DOIT attester que le nœud fonctionne sur un serveur protégé par un pare-feu qui, au minimum : interdit l’entrée publique sauf sur les ports utilisés par le logiciel du nœud (différentes machines peuvent choisir d’exposer les fonctionnalités du registre distribué sur des ports différents, donc aucune configuration de port standard n’est requise); autorise les SSH de manière optionnelle, le Bureau à distance (Remote Desktop) et des outils d’accès à distance similaires, mais limite l’entrée pour ces outils de manière à exclure le public tout en permettant l’accès aux administrateurs ; restreint les ports de sortie pour limiter la capacité de se déplacer du nœud vers un autre emplacement.
8. DOIT exécuter l’outil de vérification de sécurité de l’Intendants comme demandé et DOIT obtenir l’approbation du Comité directeur ou d’un groupe technique délégué des résultats avant que le nœud ne soit autorisé à participer au consensus.
9. DOIT exécuter l’outil de vérification de sécurité de l’Intendant de temps à autre selon les demandes du Comité directeur et fournir le rapport des résultats des tests au Comité directeur dans un délai de trois (3) jours ouvrables.
10. Le nœud DOIT être régulièrement analysé à l’aide d’outils de sécurité et de protection contre les menaces.

Un Surveillant de réseau :

1. DOIT garder confidentielles les informations privilégiées sur les nœuds et n'utiliser ces informations que pour aider les Intendants à assurer la santé et la disponibilité du réseau.

Exigences relatives au fonctionnements des nœuds

Un Intendant :

1. DOIT fournir à au moins deux (2) responsables techniques, chargés de l’administration du nœud de l’Intendant, un appareil qu’ils peuvent utiliser comme dispositif d’alerte en temps réel.
2. DEVRAIT s’efforcer de faire en sorte que son nœud atteigne un temps de fonctionnement d’au moins 99,9 %, ce qui représente environ 1,4 minute de temps d’arrêt par jour ou 9 heures par an). Cela exclut les temps d’arrêt pour les mises à niveau et la maintenance.
3. Les arrêts planifiés DEVRAEINT être coordonnés à l’avance avec les autres Intendants via un mécanisme déterminé périodiquement par accord entre le Comité directeur et tout autre organe de gouvernance du CICAN pertinent.

Mesures techniques et organisationnelles du réseau CANdy

Le réseau CANdy DOIT maintenir des mesures techniques et organisationnelles que les membres opérant des nœuds CANdy doivent impérativement mettre en place afin de garantir un traitement sécurisé, prévenir les violations de données et faciliter le respect des obligations pertinentes de protection des données.

Les membres qui exploitent des nœuds CANdy doivent adhérer aux mesures techniques et organisationnelles suivantes :

• Les coordonnées des ressources techniques.
• Les processus permettant le maintien à jour des coordonnées des ressources techniques.
• La gestion des départs de ressources techniques.
• L’accueil et l’intégration de nouvelles ressources techniques.
• Les services de surveillance.
• Les notifications et alertes d’incidents et de pannes.
• L’escalade des incidents, y compris en dehors de l’équipe (administrateurs de confiance, Comité directeur et Conseil de gouvernance).
• L’attribution des responsabilités en période de crise.
• La stratégie de communication relative aux incidents et aux pannes.
• Les protocoles de réunion en cas d’incident.
• L’examen post-incident sans reproches.
• Dossiers d’exploitation contenant des actions à entreprendre pour résoudre les incidents potentiels.